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loged at creation. Datasets may also exist on private devices, either 
disks or tapes. Private datasets may be cataloged or not, as the user 
desires. Only disk datase | 


` 


ts in the "virtual access method" (VAM) are 
supported by TSS Server File Transfer, but private VAM datasets may be 
used if cataloged. le TSS commands exist for transferring VAM data- 
sets to tape, cards, printer, etc, 


The TSS catalog structure also allows extensive sharing of datasets 

z may be done at eny qualification level and 
with read-only, infimited access (only unlimited sharing 
allows erasing). To share a TSS dataset, the owner must first "permit" 
it to one or more users. Each user must then explicitly "share" it, 
which causes an entry for the dataset to be made in his catalog. This 
entry, which may be under a different name than the original, do#s 
not point to the dataset itself, but rathe: points to the appropriate 
entry in the owner's catalog. ‘This allows the owner to change or re- 
move sharing access at any time. 


among usé 


ae 


TSS FILE STRUCTURE 


A brief discussion is also in order about the difference between un- 
structured files and record-structured files. All files on TSS are 
stored with some form of record structure, although each record may be 
up to one million bytes in length; the important thing is the meaning 


attributed to a record. 


For character oriented date ` 
documentation) a record corresponds to a line; there are no end-oọof- 
record markers in the data itself (CR-~LF, NL, EOL). The TSS editors 
require this, the translato require this and so forth. This does not 
character (NL) in the cata, how- 
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preclude having an EBCD 
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ever; it is just treated as part of the line of data. Thus character 
oriented files must be sent to and stored on TSS with record struc- 
turing to be ageku bi 


The use of unstructured files on TSS is usually restricted to binary 
data and object programs, From the network the only use for such files 
would be data which is in fact a totally unstructured string of bits 
(using IMAGE type). An example might be an object program for an IMLAC. 


Because of the above, our server has implemented the following con- 
ventions. 


Sending structured data (RETR, STRU R): 


An end-of-record sequence will be added to each record read from 
the TSS dataset (either "stream" mode CR-LF or "text" mode EOR). 


Sending unstructured data (RETR, STRU F): 
The data will be sent with no end-of~record sequence added. 
Receiving structured data (STOR or APPE, STRU R): 


An end-of-record sequence is required to define each TSS record 
(with a maximum record length of 1012 bytes). 


Receiving unstructured data (STOR or APPE, STRU F): 
Every character received is written into arbitrary sized records 
(except for “text" mode EOF character). 


The above inplementation does satisfy one criterion (as stated in the 
third sentence of III.C in RFC 354): any file sent to TSS may be re- 
trieved exactly as sent. For example, this means that if a character 
file is sent in unstructured form, the CR-LF sequences will be stored 
as part of the data. When this dataset is retrieved (also in unstruc- 
tured form) no new end-of-record indicators will be added, so the re- 
trieved file will have only the original CR-LF record information. 

tf the file were retrieved in record-structured form, however, this 
would of course not be the case; it is important that any unstructured 
file be retrievedin exactly the same manner that it was sent. 


This criterion of retrievability is not the main one of concern to 
TSS users, however; a more important criterion is that files sent to 
TSS may be of use on that system (i.e., may be edited, may be printed, 
etc.). To accomplish this it is imperative that character data be 
sent with record structure, 


noO 


As cam be seen from the above discussion, this should not bë a problem 
with most hosts, as in cerault transfers (MODE S, TYPE A) they are al- 
eady including end-of~record information at the end of each physical 

lime (CR-LF). Thus the only requirement would be to not reject the 
STRU R command (at least in MODE S, TYPE A transfers). This may cause 
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it is strongly requested that hosts which do not usually store files 
in record-structured form at least implement STRU R in this simple 
context. 


| 

hi] 

some minor problems (such as CR-LF-LF-LIF-LF for vertical spacing) but if 
| 


TSS SERV 


The TSS implementation of each of the file transfer commands is des- 
cribed below. The maximum length for a command and its parameters is 
256 characters (not includir “the CR-LF at the end). All blanks are 
removed from the parameter string, and so blanks are never significant 
except to separate a command from its parameters. 


is no active 


here 
USER command. 


Only the maas MAIL and MLFL may be used when th 
user logged or; all other commands require a prior 


The USER commend defines the TSS userid to be employed for catalog ac- 
cess. This must be a valid TSS userid, but it must also have been 
specified as having access to network file transfer. This is done by 
installation management in a manner similar to establishing a valid 
TSS userid; contact Wayne Hathaway to have existing TSS userids joined 
to ARPA Network File Transfer. The demonstration userids ARPA, ARPAI, 
and ARPA2 do have access to file transfer. 


The USER command also resets all file transfer parameters to their 
default values, including HOST and SOCK. It is felt this should have 
been specified in the protocol. 


3 


If a USER command is entered during a file transfer operation it will 
a he until the transfer is complete; th w userid will then 

be held until the t e compl ; the new d will be 

processed, a password may be requested, etc, 


PASS 


TSS file transYer passwords are optional and are established when userids 
are granted file transfer access. This password is not necessarily the 
same as the normal TSS password. The demonstration userids ARPA, ARPAIL, 
and ARPA2 have no passwords. 


ACCT 


The ACCT command is not supported. 


The protocol seems somewhat deficient in the definition of the ACCT 
command, particularly in the assigning of reply codes. I would like 
to propose that code 331 be assigned to "ENTER ACCT" when the ACCT 
command is required for "lag-on" and code 433 be assigned to “ENTER 
ACCT" when the ACCT command is requi:ed only for a particular transfer 
operation. Tt is felt that this would aid user automata in satisfying 
particular server requirements 
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BYTE 
The only BYTE size supported is eight. 


SOCK 


The SOCK command is supported in accordance with the protocol. There 
is only one HOST parameter, however, which applies to both send and 
receive sockets, 


TVR 
TYPE 


Types currently supported are ASCII and IMAGE. The EBCDIC type will 
be added later. The two "print file” types are not yet supported, due 
partly to lack of time and partly to a seeming fault in the protocol: 
it appears the only mode which allows a "print file" is BLOCK. 
This is based on the descriptions of transfer modes on page 12 of RFC 
354: TEXT mode al niy ASCII type, and STREAM made allows record 
structures (surely necessary in print files) only in ASCII type. I 
assume this is an I intend to support EBCDIC 
type in STREAM mode with “record structures (since EBCDIC contains both 
CR and LF). If not, the implementation of "print file" types will be 
elayed substanciel ly. 


ne 
pe 
n 
Bh 


STRU 


Both file and record structures are supported, in accordance with the 
I > 
pretecol. The EBCDIC type will be supporced with record structure, 
however, as indicated under the TYPE command. 
3 


The STREAM and TEXT modes are currently supported for the indicated types 
(STREAM is required for IMAGE type). In STREAM mode with record stru- 


tures, the CF-LF sequence (with optional Telnet NOP's) is required as 
EOR. In TEXT mode with no record structure any EOR characters encoun- 
tered are discarded. EXT mode with record structure a message con- 
taining only an EOF character is assumed to be an end-of-file only, not 

a null record with an omitted EOR (although we would like to continue 
our lobbying against “implied EOR" concepts!). 


The RETR conmand is supported in accordance with the protocol;. the para- 
eter must be a fully qualified name of an existing dataset on direct 
access storage (public or private). For structured files in ASCII type 
a "CR-LF" sequence is inserted at the end of each record. No EOR char- 
acters are inserted for unstructured files in TEXT mode, 


STOR 


The STOR command is supported in accordance with the protocol; the para- 
meter must be a valid fully qualified dataset name, with unlimited or 
read-write access required for existing shared datasets. The charac- 
teristics of the TSS dataset being stored are determined as follows. 


RFC 418 Page 6 


For new datasets, the default characteristics are VS organization with 
m record size of 1012 bytes. This may be overridden by speci- 
fying an ALLO (TSS "DDEF") command with different characteristics. A 
TSS "line dataset" may thus be created by first entering an ALLO com- 
mand specifying VI organization (line mmbers will be inserted by the 
system). For other types of VI datasets, however, the user must ensure 
that the records contain keys in the specified positions and that they 
are sent in order by key; it is anticipated that this facility will 
be rarely used, 


For existing datasets, the new version will be created with the same 
characteristics as the original (and on the same private volume), 


APPE 


The APPE command is supported in accordance with the protocol; the 

parameter must be a valid fully qualified dataset name, with unlimited 
or read-write access required for existing shared datasets. The char- 
acteristics of created datasets are determined as for the STOR command. 


RNER 


The RNIR command is supported in accordance with the protocol; the para- 
meter must specify the fully qualified name of an existing dataset. 


RNTO 


The RNTO coumand is supported in accordauce with the protocol; the para- 
meter must specify the fully qualified name of a nonexistent dataset. 


DEVE 


Due to the TSS file sharing and private device facilities, the single 
DELE command is not really adequate. In TSS there are two separate 
commands for this function, ERASE and DELETE. The ERASE command is 

used to actually purge a dataset and free its space; it may be used 

only on direct access datasets (public or private) with unlimited access. 
The DELETE ccmmand simply removes a catalog, entry and does not touch 

the dataset itself; it may be used on shared datasets of any type (to 
effectively "unshare'') or on datasets on private devices. To attempt 

to provide both of these functions, the DELE command has been imple- 
mented as follows. 


For nonshared datasets: 


Public or private direct-access: 
erase (free the space) and delete the catalog entry 


Private nondirect-access: 
delete the catalog entry only 


For shared datasets: 


Public or private direct-access, unlimited sharing: 
erase (free the space) and delete the catalog entry. 
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All others: 
delete the sharer's catalog entry only 


ALLO 


The ALLO command is used to enter a TSS "DDEF' command. This may be 
used to specify nonstandard dataset attributes, private devices, or 
other items. The parameter is a complete TSS "DDEF" command minus the 
word ciel itself, with the minor restriction that the first three 
paramete ME, DSORG, and DSNAME) must be present and must not 
be specified in keyword format. 


AN EL 


REST 


The REST. command is not supported. It will be added when BLOCK mode 
is implemented. 


STAT 


There are three uses of the STAT command. Jf used between file transfers 


with no parameter, it will print the current values for all file trans- 
fer parameters (user, byte size, host, receive data socket, send data 
socket, transfer type, file structure, and transfer mode). If used dur- 


ing a file transfer operation (with or without a parameter) it will indi- 
cate what type of operation is active. 


The third use of STAT is to retrieve status information about a file or 
group of files (i.e., any qualification levei). There are two forms for 
this information, termed short and long. The short form will indicate 
xist with the qualification level specified, with infor- 
rivate devices. If the parameter specified 
the entire dataset \ê is printed. If it 
is partially qualified, the names of all datasets in that group are 
printed (with only the unique portion of the names actually appearing). 
This short form is exactly equivalent to the TSS "PC?" command and is 
the default foim for STAT. 


rhat a . 
what aata 


mation about sharing and 


is a fully qualified na 


The parameter for the long form is the same as for the short form, but 
all available information is printed for each dataset (at least five 
lines per dataset). To get the long form, the characters '', LONG" must 
be appended to the BaFeRS has - The long form is exactly equivalent to 
the TSS "DSS?" command 


The STAT command does not currently send a reply code 200 at all. It 
is felt this should be added to the protocol to better define the end 
of STAT information; the reply code 200 will be added at that time. 


LIST 


The LIST command produces output identical to the short and long form 
STAT command (parameter required) except that the long form is the de- 
fault; to get the short form, the characters '',SHORT' must be appended 
to the parameter. 
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The ABOR command may be entered at any time during a file transfer oper- 
ation. It will cause an immediate termination of the transfer and clos- 
ing of the data connection. For RETR operations, the TSS dataset will 
be unaffected. For STOR or APPE on a new dataset, there will be nothing 
created (except possibly an intermediate file which should be ignored). 
For STOR of an existing dataset, the dataset will be unchanged. For 
APPE to an existing dataset, all transferred information will have been 
written into the dataset. 


The BYE command is supported in accordance with the protocol. If a BYE 
command is entered during a transfer operation. the next command entered 
(which must be a USER command) will not be processed at all until the 
transfer is complete. Note that this precludes aborting the transfer 
after a BYE command is entered (which seems to fit the spirit of BYE). 


MATL 


The MAIL command will accept a TSS userid, a known NIC ident (i.e., one 
for which a mapping to TSS userid exists), or a null parameter ( in 
which case the mail will be sent to the TSS systems programming group). 
Unknown idents will cause the MAIL command to be ignored. 


The MAIL command may be entered prior to the first USER command, to in- 
crease the tility of the network mail system. This is not currently 
mentioned in the protocol; it is felt that this implementation should 

i 


be recommended, 


MLFL 


The parameter is the same as for the MAIL command. 
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The MLFL commend may o be entered prior to a USER command, for the 
same reasons indicated under MAIL. 


COMMENTS ON TRE PROTOCOL ' i 


Some possible additions to the File Transfer Command Set are as follows. 
NOP 


It seems strange to find any protocol without a no-operation command, 
and there are several possible uses for such a command. Assuming 
there is a special reply code assigned to "NOP COMMAND ACCEPTED," 
then NOP could serve the same function as the level 2 ECO (for user 
verification of server existence, for example). Another example could 
be in allowing the user to discard terminal output, as from a too- 
lenghty STAT command. The problem with just discarding everything is 
that the user process does not know when all output has been received. 
If a NOP command were defined, the user process could send a NOP upon 
receipt of the discard request, and then discard until the unique NOP 
response is received. 
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SRVR 


The SRVR command would be used to pass a parameter which has signifi- 
cance only to the particular server system. This parameter might 
specify printing a newly created file, moving a file, or any number of 
server-defined functions. One possible implementation would be for the 
parameter to be a valid server system command, which would then be 
"obeyed" by the server 


To simplify implementation of both SRVR and STAT commands, the follow- 


ing change to the protocol is requested. Between the receipt of a 
STAT or SRVR command and the sending of a recognizable reply code (i-e., 
any message with numbers in the first three positions), a server is 


allowed to send ages which do not have valid reply codes. Thus the 
server system response messages could be sent with no modification (ex- 
cept to insure that the first three positions are not numeric). These 

messages would be assumed to have code 000 and should be printed by 

any user processes. This technique could possibly be extended to other 
commands with good results. 


CLSE 


During implementation of the File Transfer Server the following operat- 
ing mode was considered, that of the so-calied "hot card reader." In 
this mode a connection would be established between two systems once 

to be left cpen for an extended period. Individual users would enter 
USER comma fer files, and then enter BYE commands to safe- 
guard their files. For this mode the BYE command should not close the 
TELNET connection. In fact, this is the def 


‘inition of the BYE com- 
mand if entered during a transfer and if a new USER command comes be- 
fore the transfer is complete. 


To eliminate the timing uncertaintities of the BYE conmand, and also 
to allow the “hot card reader" mode, it is recommended that the BYE 
command be redefined to mean "terminate the currently active user and 
require a new USER command before additional transfers." The TELNET 
connections could of course be closed by tha user: process as soon as 
the EYE command is acknowledged. For user processes that cannot or 

do not choose to do this, a new command CLSE should be added, to have 
the meaning of "close the TELNET connection when possible (i.e., after 
any active transfer is complete)." 


Thus BYE would have only the meaning it currently does if entered during 
an active treme kee and CLSE would have the current meaning of BYE in 
other circumstances. Further suggestions would be that CLSE implies a 
BYE and that a CLSE during an active transfer "logically" closes the 
connection immediately (i.e., no commands may be entered while waiting 
for the transfer to complete). 


Some small items missing from the protocol are now mentioned. 
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DEFAULT PARAMETER VALUES 


It should be more emphatically stated that servers must assume default 
values for all unspecified parameters (MODE, TYPE, etc.). Without this, 
all user processes must always send a complete set of parameter speci- 
fication commands, since some server somewhere may not make the correct 
default assumptions. This is obviously undesirable. 


SYNCH ON THE TELNET CONNECTION 


The protocol states that the ABOR command should be preceded by the 
Telnet SYNCH condition, for reasons of efficiency (so that servers do 

not need to be continually checking the Telnet connection during a trans- 
fer). This should be extended to other conmands which may be used dur- 
ing a transfer (BYE, USER, STAT, etc.). 


BREAK ON THE TELNET CONNECTION 


The question of what a BREAK character mears over the Telnet connection 
is not touched. Even if the BREAK is to heve no function this should 
be specified. In the TSS implementation, the only time a BREAK is re- 
cognized is during a MAIL command; the BREAK will abort the conmand and 


cancel the mail. 


CATCH-ALL REPLY CODES 


It is felt that one reply code of each type should be assigned the mean- 
ing of "other" so that system-dependent cvents could be properly iden- 
tified. For example, if an indexed file is being sent to TSS and records 
are received out of order, the reply code currently used is 453, although 
this is supposed to mean "insufficient space." If a catch-all code were 
defined, the message text could be used to further specify the exact 
meaning. 


PARAMETER VALIDATION 


Certain server processes (notably TENEX) have apparently divided the file 
transfer commends into two HORSE groups: parameter setting commands 
and file manipulation commands. The parameter setting commands are TYPE, 
MODE, STRU, and BYTE. The catemeter values specified on these commands 
are not validated when received; they are simply stored and a reply code 
200 is returned. The parameters are validated on the next file manipu- 
lation command, however, with errors resulting in cancellation of the 
file manipulation command itself with reply code 503. 


I am aware of the problems with validating parameters when received (i.e., 
of temporarily producing invalid combinations when changing from one valid 
set to another) but it is felt that some standard could be set up to allow 
this. As an absolute minimum, totally invalid or unsupported parameter 
values should be diagnosed immediately (€.g., MODE B if BLOCK mode is not 
implemented). 


This problem is a nuisance with a human user, but it becomes quite serious 
with a user automaton: the amount of work necessary for an automaton to 
empirically determine a valid set of parameters is intolerable. 


